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ABS TRAC T ; 

What is mission operations? Mission operations is an iterative process aimed at achieving the greatest possible mission success 
with the resources available. The process involves understanding of the science objectives, investigation of which system 
capabilities can best meet these objectives, integration of the objectives and resources into a cohesive mission operations plan, 
evaluation of the plan through simulations, and implementation of the plan in real-time. 

In this paper, the authors present a comprehensive description of what the Hitchhiker mission operations approach is and why it 
is crucial to mission success. The authors describe the significance of operational considerations from the beginning and 
throughout the experiment ground and flight systems development. The authors also address the necessity of training and 
simulations. Finally , the authors cite several examples illustrating the benefits of understanding and utilizing the mission 
operations process . 


INTRODUCTION 

The mission operations process starts at the earliest stages of 
Hitchhiker Project and customer interaction and culminates 
in on-orbit operations. Experience has proven that an 
attention to operations is integral to the development and 
ultimate success of a Hitchhiker Payload. 

Ideally, payload operations activity begins even before an 
experiment is manifested as a shuttle payload. At this stage, 
when experiments are still being conceptualized, mission 
operations plays a crucial role. A customer can design an 
experiment to maximize the possibility of mission success 
by understanding the capabilities and limitations of the 
Hitchhiker and Orbiter systems up front. 

The Hitchhiker operations group aims to capitalize on the 
wide range of services and capabilities available to 
Hitchhiker customers. As the team investigates which 
capabilities can best meet science objectives, compatibility 
between payload requirements and Space Shuttle Program 
(SSP) resources is determined. Mission Operations is a 
driving factor in the definition of the Space Shuttle 
Manifest. 


mission operations plan through an interactive dialogue 
between Hitchhiker, Orbiter, and experiment personnel. The 
resulting operations plan prepares and guides the Hitchhiker 
Flight Operations Team (FOT), consisting of both 
operations personnel and experiment teams, through both 
nominal and contingency flight situations. 

MISSION OPERATIONS PLANNING 

Mission planning is a multi-faceted and interactive process, 
as illustrated in Figure 1 . Early reviews are essential in the 
planning of flight timelines and procedures. Operations 
training, provided through all stages of payload development, 
plays a fundamental role by introducing the capabilities and 
constraints of the Hitchhiker and Orbiter systems. 
Knowledge of these constraints aids in the development of 
hardware, software, and mission operations documentation 
and plans. Once the flight activities and requirements have 
been documented and the Hitchhiker ground system has been 
verified, the Hitchhiker operations group prepares 
experimenters for real-time operations through further 
classroom training and interactive simulations. 

The mission planning process involves years of preparation 
which culminate in a relatively brief period of flight. As the 
mission success of the payloads, not to mention the safety 
of the Orbiter and crew, are dependent upon the thorough 


Once a payload is manifested on a compatible flight, 
requirements and resources are integrated into a cohesive 
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Mission Ops Milestones 

(in months) 

L-24 

TIMs/CPR 

L-18 

PIP & Annexes 

L-18 

Train #7 

Lr 18 

POWG 

L-13 

DMR 

L-12 

SRR 

L-12 

CIR 

L-6 

Train #2 

L-6 -L-3 

GDSI&T 

L-6 

Crew Brief 

L-6 

Pre-Ship Rev. 

L-6 

FAM, POWG 

L-6 

SDR 

L-3 

FOR 

L-3 

Train #3/MOD 

L-3 - L-l 

Sims 

L-l 

ORR 

L-l 

FRR 


Figure 1: Mission Planning Process 


Documentation/Event 

Corresponding Review 

• Customer Payload Requirements ( CPR) 

• Technical Interchange Meeting (TIM) 

• Training #1/ 

Payload Integration Plan (PIP) 

• Payload Operations Working Group (POWG) 

• Cargo Integration Review (CIR) 

• Detailed Mission Requirements (DMR) 

• System Requirements Review (SRR) 

• System Design Review (SDR) 

• Ground Data System I&T ( GDS I&T) 

• Ship to KSC 

• Pre-Ship Review 

• Document Publication/Training #2 

• Crew Brief/Familiarization Brief (FAM) 

• Payload Operations Working Group (POWG) 

• Flight Operations Review (FOR) 

• Simulations/T raining #3 

• Mission Operations Document (MOD) 

• Sim Debrief 

• ”GO ! ’for Launch 

• Operational Readiness Review (ORR ) 

• Flight Readiness Review (FRR ) 


planning and preparation of the entire flight team, final 
simulations and reviews are held to verify the flight readiness 
status of all supporting elements, both human and 
mechanical. 

Flight Operations Documentation/Meetings 

Payload Requirement Defimtion 

The earliest stage of the mission operations planning process 
is concentrated about the generation of documentation within 
the customer's facilities and at the Goddard Space Flight 
Center (GSFC). Early technical interchange between the 
Hitchhiker team and the customer is crucial in the definition 
of payload requirements and the development of the 


experiment flight and ground systems. These preliminary 
meetings, designated Technical Interchange Meetings 
(TIMs), are ideally scheduled approximately two years prior 
to flight. TIMs provide a forum for the discussion of 
payload requirements and goals as defined in the agreement 
between the Hitchhiker Project and the customer, the 
Customer Payload Requirements (CPR) Document. The 
CPR contains a myriad of detailed experiment information: 
operation cycles, crew involvement, command/telemetry 
requirements, power requirements, ground system 
requirements, Orbiter pointing restrictions, instrument field 
of view, descriptive material and mission objectives. The 
Mission Manager (MM) utilizes the CPR and information 
gathered at TIMs to oversee the integration of the customer's 
experiment with the Hitchhiker and Orbiter communities. 
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In preparation for the HMs, the MM gathers lead personnel 
from various disciplines supporting Hitchhiker missions to 
discuss payload integration issues and payload operational 
requirements and constraints. The team leads are then 
responsible for generating and maintaining documentation of 
payload requirements and specifications for submittal to the 
Johnson Space Center (JSC). The Operations lead, 
designated the Operations Director (OD), maintains an on- 
going dialogue with the customer point of contact 
throughout the mission operations planning process and 
verifies his/her work through customer feedback. The OD 
also supports payload status meetings to determine if 
payload development and integration issues could impact 
mission operations. 

The OD supplements the TEMs with preliminary mission 
operations training sessions, providing the customer with an 
early awareness of the operational capabilities and constraints 
of the Orbiter and Hitchhiker systems. From these sessions, 
an expanded definition of payload requirements materializes 
and the OD begins to analyze customer requirements versus 
the wide range of services and capabilities available. 

As payload development progresses, the OD integrates 
payload requirements into both joint (between the JSC and 
all payloads) and Hitchhiker specific documentation and 
support JSC in the final preparation of these documents. 
Hitchhiker specific documents are developed defining internal 
operations to be followed by the Hitchhiker FOT. The 
operations training provided throughout development aids in 
the definition and refinement of these requirements. 
Engineering and operations reviews are held throughout the 
mission planning process to analyze the 
compatibilities/conflicts between various payloads. 

Joint Mission D ocumentation and Related Re v iews 

Utilizing the information in the CPR, the Hitchhiker team 
leads prepare the Payload Integration Plan (PIP) and its 
annexes. The PIP is the contract between the Hitchhiker 
Project, on behalf of the customer, and the SSP. General 
mission operations information relating to those 
requirements that affect the manifesting of the Hitchhiker 
payload with other payloads is contained within the PIP. 
Specific mission operations requirements and specifications 
between the Hitchhiker program and the JSC SSP are defined 
in the PIP annexes. The OD prepares annexes covering 
electrical and power requirements, flight activity planning, 
flight operations support, crew training, and Payload 
Operations Control Center (POCC) interfaces and aids the 
MM in the development of the PIP. These documents form 
the basis for detailed operations documentation by outlining 
specific Hitchhiker customer requirements and mission 
objectives. Payload Operations Working Group (POWG) 
meetings may be called to support the definition of payload 


requirements and to resolve any issues during the 
development process. 

After submittal of the PIP and Annexes to the JSC, payload 
representatives attend a Cargo Integration Review (CIR) at 
which the SSP assesses the compatibilities between the 
manifested payloads as well as the capabilities of the SSP to 
meet payload requirements. As stated earlier, mission 
operations requirements are a driving factor in the 
consideration of payload compatibility. Once the SSP feels 
confident that all mission requirements can be met, the 
shuttle manifest is formally solidified and the PIP and 
Annexes are baselined. 

A basic version of all flight documentation products, 
including the Flight Data File (FDF), is then developed from 
the requirements in the baselined PIP and Annexes. The 
FDF is the total on-board complement of documentation and 
related aids available to the crew for execution of the flight, 
including operations plans, crew checklists, and reference 
data. The Flight Plan is the most significant component of 
the FDF as it is the control document for on-orbit 
operations, tying mission operations together by timelining 
the crew, Orbiter and payload activities. The Flight Plan is 
developed pre-mission and is updated daily during the flight. 
Various other documentation is developed to coordinate 
ground operations. These documents govern nominal 
procedures and define payload priorities and constraints for 
consideration in contingency scenarios. 

All flight operations documentation is published in basic 
form approximately 6 months prior to launch. At this time 
the documents undergo extensive review by mission 
personnel. The OD involves the customer in this review 
after providing training on how to read and interpret flight 
documentation. The OD then submits any discrepancies to 
the published documentation to the SSP at the Flight 
Operations Review (FOR). The OD represents the customer 
at the FOR to ensure that all payload requirements are 
properly reflected in the final set of flight documentation 
products, which are used for both simulations and on-orbit 
operations. 

The documentation process is fundamental to flight 
preparation and mission planning. The OD and the MM use 
the flight documentation to ensure that payload operational 
requirements and constraints are not intentionally violated 
during the flight. These documents facilitate mission 
operations by prioritizing and organizing on-orbit activities 
while also providing an assurance that all feasible efforts 
will be made to preserve and achieve payload goals. 

GSFC Specific. Documentation and Re lated Re vi ew s 

The overall objective of the Hitchhiker Project is to provide 
service to a variety of customers via standard interfaces as 
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defined in the Customer Accomodations and Requirements 
Specifications (CARS) document that can be used for 
experiment design and development, as well as mission 
operations. To this end, the Hitchhiker Ground Data System 
(GDS) utilizes standardized capabilities available at the 
GSFC. The OD provides training on these capabilities and 
works with the customer to define which services will best 
meet their needs. 

Utilizing this information, the OD, in consultation with the 
Mission Support Manager (MSM), determines which GSFC 
elements are required to support the mission and outlines 
these requirements in the Detailed Mission Requirements 
(DMR) document. The MSM, who is responsible for the 
configuration of the GDS, then monitors the design and 
implementation of the requirements through a detailed review 
process. 

As the DMR outlines the requirements of the Hitchhiker 
GDS, the Mission Operations Document (MOD) generated 
by the OD outlines the operational procedures to be utilized 
within the POCC. The MOD provides Hitchhiker 
operations personnel with guidelines to ensure an orderly and 
efficient operations center, as well as pre-planned decisions 
to minimize the response time to anomalous events. 

The customer is responsible for developing detailed 
experiment operational documentation governing experiment 
flight procedures, such as console procedures, command 
plans, and contingency recovery plans. These procedures 
guide real-time experiment operations within the Hitchhiker 
POCC during simulations and flight. Many customers use 
the Hitchhiker Timeline System (HTS) product as a 
guideline in the preparation of operational plans and 
procedures. The HTS, developed exclusively for the 
Hitchhiker Project, provides operations personnel with 
communication availability predictions, Orbiter pointing 
predictions and payload activity timelines. The HTS product 
is based on the Flight Plan and supporting JSC documents. 
However, unlike the Flight Plan it is updated at the POCC 
in real-time. This proves a valuable tool through training, 
pre-mission planning, and flight by providing the POCC 
with a locally controlled operations timeline as well as with 
planning information not readily available from the JSC 
during a Shuttle flight. 

Regardless of the time spent preparing nominal plans, actual 
on-orbit operations often bring rise to contingency situations 
in which nominal operational scenarios become unsuitable. 
Thus it is important that customers take into account all 
possible operating scenarios, regardless of improbability, in 
preparation for a mission. Unlike a world of free-flyers, 
where scientists have days, if not months, in which to 
troubleshoot a problem, shuttle flights offer a relatively 
short period for implementation of the experiment timeline. 


Pre-mission contingency planning is critical for a successful 
flight. The OD aids the customer in the development of off- 
nominal scenarios pre-flight and facilitates the on-orbit 
execution of contingency resolution in a timely and efficient 
manner. 

All internal GSFC documents and reviews are geared towards 
the creation of a functional and operational ground system. 
As the DMR outlines the resource and service requirements 
of the payload, the MOD guides the daily activities and 
duties of the operations personnel, and the experiment 
procedures govern the real-time operations of the payload. 
The procedures and protocols in the MOD foster an 
atmosphere geared to the success of real-time operations. 

Mission Training 

In the early years of the Hitchhiker program, mission 
operations training was provided informally throughout 
payload development and presented in a formal session 
relatively close to flight. Although some experiments 
manifest as a Hitchhiker payload after system design is 
complete, some experiments manifest early enough in the 
development process for training to influence experiment 
design. Several customers have responded that an earlier 
insight into the resources of the Hitchhiker system would 
have helped them to design their experiments better by using 
more of the services available to them. Thus a new training 
approach has been adopted, one which offers formal training 
at at least three points through payload development and 
mission planning. This training is offered early and is 
repeated often throughout the development process. 

Mission Operations Training 

Payload Mission operations are driven by the capabilities and 
limitations of the resources at hand. Understanding the 
nature of Orbiter to ground communications, standard 
operational contamination factors, and GDS capabilities is 
imperative for maximizing science return during a mission. 
To provide this essential Hitchhiker education, a series of 
classroom training sessions is held to familiarize customers 
with Hitchhiker and Orbiter services, data systems 
configurations, and all aspects of mission operations as 
shown in Figure 1 . 

The first training session introduces the capabilities of the 
Orbiter telecommunications systems, addresses the concept 
and function of the Hitchhiker ground system, and 
summarizes contamination factors that may impact payload 
operations. This session plays an important role in payload 
development as experimenters can channel the design of their 
hardware and software both on-orbit and on-ground to the 
capabilities and constraints of the operational systems. For 
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This diagram illustrates only a small 
portion of the operational systems and 
or factors which often enhance, and 
sometimes degrade, yet always dictate. 
Hitchhiker mission operations. 

Hitchhiker experiments produce low 
rate (LR) and medium rate (MR) data 
which is transferred to the ground 
through the Orbiter S-Band and Ku-Band 
systems via the Tracking Data and 
Relay Satellite (TDRS) System 
(TDRSS). The Orbiter records LR data 
during Loss of Signal (LOS); MR data 
is not recorded. Communications via 
the TDRSS can be constrained by many 
factors, such as loss of sight to a TDRS 
due to the TDRS Zone of Exclusion 
(ZOE) or structural blockage, handovers 
of communications from one TDRS to 
the other, corrupted or weak 
communication signals due to 
interference, or conflicting Orbiter or 
payload requirements for dedicated 
satellite communications. 



Shaded areas indicate a loss of communications between the Orbiter and the TDRSS. 


Figure 2: TDRSS Communication Constraints 


example, experiments relying heavily on medium rate data 
may be influenced to add a recording device onto their 
payload to ensure that communication outages, some of 
which are illustrated in Figure 2, will have a minimum 
impact on their operations planning. Other experimenters 
may opt to design their command interface to allow serial 
commands in lieu of basic bi-level operations. 

This initial training also plays an important role in the 
definition and requirement of system constraints. A flight 
constraint may sometimes be no stricter than a requirement 
that the Hitchhiker POCC be notified prior to a deviation 
from the planned contamination event or timeline. The 
reasons for this are two-fold: to safe instruments that may 
be wary of contamination yet who do not require an inhibit, 
or to enhance the science opportunities for payloads wishing 
to observe contamination events. 

The most important function of this preliminary training 
session is to raise experimenter awareness of all of the 
factors that will dictate mission operations. The training 
provides the information necessary for the customer to levy 
informed requirements and constraints on the SSP through 
the operations documentation outlined before. 


The second operations training session describes flight and 
ground documentation used during on-orbit operations. 
These documents form the basis for all payload operations 
and coordination. It is vital that experimenters can interpret 
and understand the flight documents which outline all 
mission operations. The OD instructs the customer on how 
to read the Flight Plan, Operations Timelines, Attitude 
Timelines and the HTS, with emphasis on all details which 
will prove critical in timelining experiment operations. The 
customer learns how to use the HTS as a mission planning 
tool, above and beyond those provided by JSC. The OD 
presents this training as soon as the basic version of flight 
documents are published, facilitating customer participation 
in the FOR process. 

The final mission training session is held immediately prior 
to the first simulation. This training focuses on real-time 
operations within the control center. The OD introduces 
many JSC-generated products which will be utilized in real- 
time during the mission and simulations, such as the 
Execute Package (Flight Plan). Additional Hitchhiker- 
specific products such as the HTS, contamination schedules, 
and status reports will also be distributed regularly to all 
users in the POCC during missions and simulations. The 
OD presents the MOD which outlines the important 
procedures that govern day-to-day operations within the 
POCC, such as shift handover guidelines, shift reports, and 
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voice protocol, and covers the distribution of products 
outlined above. The classroom session is supplemented with 
hands-on familiarization with POCC equipment. 

The expansion of the training process through all stages of 
payload development offers more flexibility in customer 
support and involvement. Training sessions are often 
performed multiple times to train additional personnel or 
simply to reacquaint those previously trained with highlights 
from earlier sessions. 

Crew/JSC Flight Operations Team Training 

Approximately six months prior to launch, the MM, the 
OD, and the customer hold a Familiarization Briefing at the 
JSC to train the JSC FOT on the Hitchhiker payload. 
Around the same time, the crew visits the GSFC for the 
Crew Briefing at which the crew is briefed on the Hitchhiker 
payload goals and operations and views the payload hardware. 
Although crew involvement in the majority of Hitchhiker 
payloads operations has been generally limited to activation 
and deactivation of the payload and the possible 
establishment of observation attitudes, some payloads place 
significant responsibilities upon the crew. Thorough 
training provided by the JSC Training Team under the 
direction of the OD is essential in the success of crew- 
intensive payload operations. 

Ground Data System Development and Test 

The Hitchhiker Mission Readiness Manager (MRM) is 
responsible to the MSM for providing and verifying the 
Hitchhiker GDS ground system based on the DMR 
requirements. The Hitchhiker MRM verifies the 
functionality of the GDS with the payload and the JSC 
MCC through a series of tests beginning in conjunction 
with the payload integration activities and continuing until 
launch. 

Customer experiments are delivered to the GSFC where they 
are electrically and mechanically integrated to the Hitchhiker 
carrier. After all experiments have been fully integrated, the 
MRM conducts a POCC Test to verify the end-to-end 
capability of the Customer Ground Support Equipment 
(CGSE), located at the Hitchhiker POCC, to communicate 
with the payload via the GDS. During these tests, telemetry 
from the payload is recorded for use in future interface tests 
and simulations in lieu of a real-time payload telemetry 
stream. The OD and the Sim Sup may script an operational 
scenario to run through during this test as a script allows for 
operational sequence evaluation and provides greater 
dynamics to data played back during the simulations. 
Following these activities, the payload is shipped to the 
Kennedy Space Center (KSC) where it is unpacked and 
readied for installation and flight. 

Further tests using taped data are performed to verify all 


interfaces and support elements that will comprise the 
operational GSFC GDS. Finally, the MRM schedules 
additional tests prior to each Joint Integrated Simulation 
(JIS) and launch to verify the command and LR telemetry 
interfaces between the JSC MCC and the GSFC. 

Simulations 

Once the Hitchhiker GDS has been verified and both joint 
and internal mission documents have been developed, 
operational simulations are conducted to verify operational 
procedures and exercise the communication between all 
operators. These simulations do not test how well 
experimenters know their systems; they evaluate whether 
the plans and procedures for real-time operations are 
satisfactory. 

Simulations are supported by the entire Hitchhiker FOT, 
composed of all operators required for real-time support 
during the mission, including the Mission Manager, the 
experimenters, the Operations Directors and all supporting 
personnel within the POCC. Simulations allow the 
experimenters to apply the knowledge gained in the training 
sessions in a realistic environment. They provide familiarity 
with the control center environment, POCC operations and 
procedures, and both inter and intra-center coordination. 
Simulations also result in a diverse forum of FOT personnel 
who can benefit each other through the sharing of operational 
experience and lessons learned. ‘Novice’ Hitchhiker 
customers can learn from the experiences of flight ’veterans'; 
while experimenters with previous Hitchhiker experience can 
learn once again how to function within a diverse and intense 
team environment. The Hitchhiker operations group 
attempts to cultivate this team environment throughout the 
simulations with the aim of a cohesive and integrated FOT. 

The Hitchhiker Program supports two kinds of simulations: 
Goddard Internal Simulations (GISs) and JISs. GISs exercise 
operational procedures and train personnel in POCC 
procedures. During GISs, the Hitchhiker ground system is 
configured using only GSFC facilities. Some supporting 
elements simulate the JSC by receiving commands from the 
POCC and playing back recorded payload telemetry to the 
experiments. These simulations test GSFC internal data, 
management, and operations interfaces and emphasize 
Hitchhiker POCC procedures. 

JISs establish operability of the overall ground system 
including the links to the JSC Mission Control Center 
(MCC). During the JISs, the ground system is configured as 
for mission operations. The JSC MCC receives Hitchhiker 
commands and forwards a composite telemetry stream back 
to the GSFC except for the Hitchhiker data which is 
simulated via playback of Hitchhiker payload telemetry 
recorded during the POCC Command Test. 
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Figure 3: Hitchhiker POCC Layout 


JISs are treated as an actual flight for the crew and all flight 
controllers and involve all facilities participating in the 
mission including the GSFC, the JSC and other remote 
POCCs. The crew participates from the Shuttle Mission 
Simulator (SMS) at the JSC which provides realistic shuttle 
subsystem data for the simulation. Coordination between 
the JSC MCC, the Hitchhiker POCC, and other payloads is 
emphasized during these exercises. System malfunctions are 
introduced which impact the mission community as a whole 
and require extensive inter-center coordination and replanning 
operations. These situations often require analysis of Orbiter 
resources and payload priorities and test the operational 
decisions outlined in the flight documentation. 

Simulations provide a medium to evaluate the effectiveness 
of the operations plan and to develop both situational 
awareness and contingency resolution skills in an 
environment representative of the actual mission, thus 
providing the best available hands-on experience for 
experimenters about to launch into real-time operations. 

REAL-TIME MISSION OPERATIONS 

The mission operations process culminates in the real-time 
implementation of the comprehensively developed, 
thoroughly evaluated operations plan. The ultimate 


responsibility of the OD is to guide and represent the 
customer, champion their interests, and coordinate real-time 
changes to the plan from launch through landing. 

Hitchhiker operations are conducted in real-time based on 
overall plans prepared pre-mission. The Hitchhiker payload 
is assigned operating periods scheduled according to the 
requirements of all manifested payloads. Some payloads 
require dedicated Orbiter support such as attitude control or 
crew interaction. The assignment of dedicated periods to all 
payloads is made based on their priority and large resource 
requirements including crew-time and power. The Hitchhiker 
FOT often must strive to take advantage of all events in the 
flight plan and all available resources to accommodate 
Hitchhiker science objectives. 

While higher priority payloads are being supported, the 
Hitchhiker may only be allowed sufficient power for 
maintenance of payload electronics and thermal conditioning. 
Low rate data and commanding may only be provided for 
periodic evaluation of payload health and safety. However, 
there may be opportunities for the Hitchhiker payload to 
operate in parallel with (piggyback) other payload 
operations. Piggyback operations are background 
operations, which take advantage of available Orbiter 
resources and gain science data on a non-interference basis 
with primary payload activity. Contingency operations are 
supported from the Hitchhiker ground system using available 
real-time command capability. 
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Payload Operations Control Center 

The focal point for Hitchhiker payload operations and 
management is the Hitchhiker POCC located at the GSFC 
in the Attached Shuttle Payload Center (ASPC). As a center 
part of the Hitchhiker GDS, the POCC provides efficient 
service to a variety of customers through simulations and 
real-time operations. It is designed for functionality with an 
attention to personnel comfort and can support several 
payloads and/or flights simultaneously. 

The POCC is composed of a Mission Operations Area, an 
Experimenter Area and a Common Area, as illustrated in 
Figure 3, and accommodates all mission operations 
personnel and equipment. It also houses the Advanced 
Carrier Customer Equipment Support System (ACCESS): a 
PC-based, distributed network that provides the central 
interface between the CGSE and the outside world. 

The POCC interfaces with the GSFC support facilities to 
provided telemetry and command for the Hitchhiker payloads. 
Additional GSFC supporting elements provide simulation 
support and attitude, orbit and data display generation. The 
POCC is equipped with a number of display devices, all 
with color capability, including large screen color monitors. 

Real-time mission operations is the culmination of months, 
perhaps years, of careful preparation. An organized and 
efficient control center offering a complete set of tools for 
replanning and real-time operations is essential to mission 
success. 

HITCHHIKER IN ACTION 

In the years since its inception, the Hitchhiker program has 
sponsored many payloads, of which the following examples 
are but a small sampling. Although all missions have seen 
their share of obstacles, the majority of Hitchhiker payloads 
have been a resounding success. Both the obstacles and 
victories alike have brought forth valuable insight that 
contribute to the success of following flights. The 
Hitchhiker operations group learns from all successes and 
failures and is thus able to continuously broaden and 
improve its scope of service. 

Superfluid Helium On-Orbit Transfer 

The Superfluid Helium On-Orbit Transfer (SHOOT) payload 
which flew on STS-57 consisted of two vacuum insulated 
dewars (tanks) containing liquid helium connected by a 
transfer line, various instrument electronics, and control 
systems mounted on a Hitchhiker cross bay carrier. The 
objective of the SHOOT mission was to perform 
experiments demonstrating the technology and operations 
required to service payloads in space with liquid helium and 
to verify several cryogenic devices and procedures in the zero- 
g environment. 


The majority of the operations involved the transfer of 
helium from one dewar to the other. Operations consisted of 
both ground-controlled and crew-controlled transfer of liquid 
helium. The crew used an Aft Flight Deck (AFD) computer 
for command and verification. These operations required 
real-time crew interaction and/or expert system software for 
diagnostic and control operations. 

During payload development, the SHOOT customer was 
developing a high fidelity simulator to aid the crew in 
training with the AFD software. After discussions between 
the SHOOT customer, the MM, and the OD, the anticipated 
role of the simulator was expanded to include training of the 
entire FOT and use during all GISs and JISs. This resulted 
in very dynamic simulations that extensively exercised the 
coordination between the ground operators and the crew in a 
realistic environment. By providing realistic telemetry for 
both the ground and the crew, the simulator allowed the 
operations personnel to rigorously test both nominal and 
contingency SHOOT procedures. This SHOOT simulator 
provided an additional benefit: a critical failure in flight was 
simulated during one JIS, thus preparing the FOT for 
contingency resolution of the problem in real-time. 

Despite some serious hardware problems on Flight Day 1, 
the SHOOT experimenters were able to accomplish all 
mission goals and milestones. They attributed this success 
to the great efforts of and coordination between the Goddard 
POCC, the MCC and the crew. They also attested to the 
value of the JISs in preparing the FOT to tackle real-time 
contingency resolution. 

Robot Operated Materials Processing System 

Mission operations often entails striving for science under 
less than ideal conditions. Yet experience has shown that 
the means for accomplishment are available, often just 
waiting to be recognized and channeled in the right direction. 
During the STS-64 mission, the Robot Operated Materials 
Processing System (ROMPS) payload required low-g 
environments through several crew sleep periods for critical 
sample processing. In order to accomplish the task, a wide 
attitude deadband was programmed into the Digital Auto 
Pilot (DAP) settings of the Orbiter. However, despite the 
wide deadbands, predictions showed that the Orbiter would 
still often reach the deadband limits too fast for a sample to 
finish processing. 

The OD prepared for this situation pre-flight by coordinating 
closely with the Guidance Navigation and Control (GNC) 
Officer at JSC to be cognizant of the signatures of the 
respective Orbiter Control System bums. Thorough 
procedures were developed and put to the test during the 
simulations. Several modifications were made, allowing 
direct contact between GNC and the OD, bypassing the 
normal flight protocol through the Houston Payloads 
Officer. During the flight, the GNC and the OD worked 
closely together to trend the timing between firings and give 
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ROMPS an emphatic “go” when sample processing times 
were assured. Several times the samples finished baking 
with only seconds to spare. This close coordination between 
the JSC and Hitchhiker FOTs helped achieve full mission 
success while operating under what could otherwise be seen 
as difficult circumstances. 

Shuttle Glow Experiment 

The Shuttle Glow Experiment (GLO) has to date flown two 
times as a Hitchhiker payload, although several additional 
flights are currently manifested. The GLO payload consists 
of imagers and spectrograph assemblies and supporting 
electronics. The primary objective of the experiment is to 
observe and qualify both Orbiter and atmospheric glow in the 
115 to 1150 nanometer spectral range. The GLO-1 
experiment aboard STS-53 experienced a combination of 
hardware problems and unlucky orbital conditions resulting 
from Orbiter and primary payload operations. As a result of 
primary payload requirements, the orbit trajectory was one in 
which the Orbiter did not have a night pass until the last day 
of the mission. Additionally, primary payload operations 
early in the flight led to propellant constraints, thus further 
limiting GLO observations. Due to these constraints the 
FOT had to restructure night observations originally 
scheduled throughout the flight to the last few orbits of the 
mission. This involved extensive prioritization, 

coordination, and replanning for both a nominal end to the 
mission and a sought for, yet ultimately denied, extension 
day. 

The GLO-II instrument flew on STS-63, with upgraded 
hardware and a heightened insight into Orbiter operations 
that only a tough mission can bring. The GLO-II 

instrument experienced some hardware malfunctions which 
required much of the flight to troubleshoot. However, the 
FOT replanned GLO science operations and had an extremely 
successful flight, regardless of the difficulties encountered. 
STS-63 was a great learning experience for the entire FOT; 
several operational issues which arose during the flight and 
were resolved in real-time prepared operators for future 
flights of the GLO instrument. 

The GLO-III experimenters have upgraded their instruments 
to add even more to their data ingestion capability; they 
have included an optical disk tape recorder which offers a 
great deal of data storage space. GLO recognizes the 
importance of an on-board recorder, as the experiment 
produces a large amount of medium rate science data that 
requires Ku-band for downlink. This addition to the GLO 
experiment adds an even greater flexibility to GLO 
operations. 

The GLO experiment is the quintessential Hitchhiker: a 

prime example of taking advantage of all opportunities and 
resources at all times. The GLO payload operates almost 
continuously throughout the mission, sometimes eking 
significant scientific data out what could be considered trivial 


Orbiter events. Through difficult flight and adverse 
operating conditions, the experimenters have continued to 
exhibit tremendous attention to experiment operations and 
replanning. This effort has rewarded the experimenters with 
success despite adversity. 

Cryo Systems Experiment 

The Cryo Systems Experiment (CSE) which flew on STS- 
63 was designed to demonstrate and characterize the on-orbit 
performance of several cryogenic system components 
contained within a standard Get-Away Special (GAS) 
canister. These components include two Stirling 

cryocoolers, a passive reversible triple-point cryogen energy 
storage device, an oxygen diode heat pipe thermal switch, 
and additional supporting electronics. CSE was designed 
with the anticipation that payload commanding would be 
sporadic and greatly unavailable. Thus the experimenters 
designed a largely self-sufficient experiment with automated 
timelines. Although the CSE mission achieved total 

mission success, the experimenters noted that early insight 
into the resources available during payload development 
could have broadened the scope of their experiment. 

HITCHHIKER 2000 

Future Trends In Mission Operations 

Both the human and technological factors within the 
Hitchhiker Project continuously evolve to new levels of 
mission preparedness and support. An important concept in 
mission operations is that there is no end in sight to this 
evolution of ideas and processes. Each success and each set- 
back teaches valuable lessons for use in future flights. 

Much like Hitchhiker operations, the POCC constantly 
evolves to best take advantage of technological capabilities 
of the Hitchhiker system. Hitchhiker plans to soon adopt a 
system of electronic flight documentation transfer. These 
documents are currently replanned and distributed daily via 
fax protocol. The adoption of electronic data transfer within 
the POCC will lessen the flow of paper products and 
decrease time-consuming practices such as faxing and 
photocopy. Hitchhiker is also currently investigating the 
possibility of increasing the capabilities of the various 
display systems in the POCC. 

Technological advancements and the world-wide adoption of 
the information superhighway have made the concept of 
remote Hitchhiker Operations Centers both possible and 
practical alternatives to pursue. Travel of personnel and 
shipment of equipment consume a significant percentage of a 
customer's budget, thus limiting funding available for other 
pursuits. Remote POCCs make sense given current 
technology and today's fiscal reality. 

During the STS-63 flight, the GLO experimenters forwarded 
near-real-time science data to their facilities at the University 
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of Arizona over the Internet. Hitchhiker will soon provide 
mission information and potentially real-time data on-line 
during flights. 

Hitchhiker mission operations personnel continue to 
endeavor for continuous improvement, always through 
implementation of lessons learned. Mission operations 
responsibilities are not over after the payload deactivates or 
even once the Orbiter comes home. As scientists will spend 
months, perhaps years, analyzing their data with a fine tooth 
comb, the Hitchhiker operations group will review every 
success and shortcoming encountered during the flight, and 
strive to implement the lessons learned through all future 
operations. 

As Hitchhiker Payloads become more complex, the 
requirements and operations become more demanding. 
Double Hitchhiker payload complements consisting of 
numerous experiments, two avionics, and two mounting 
structures, will be manifested on many coming flights. 
These payloads are comprised of a vast diversity of 
experiments, ranging from cryo-experiments, atmospheric 
spectrographs, and deployables, to Global Positioning 
System (GPS) systems and laser altimeters. Future 
Hitchhiker flights may also include Space Station based 
experiments and movable Hitchhiker carriers onboard the 
Orbiter. With mission goals becoming more ambitious, the 
importance of mission operations preparedness grows 
increasingly clear. 

By coordinating a comprehensive approach to mission 
operations, with attention to all phases of payload 
development, from the initial definition of payload 
requirements, through the integration of the objectives into a 
cohesive mission operations plan, through simulations and 
testing, and finally through the implementation of the plan 
in real-time, the mission operations group plans to ensure 
the greatest possible mission success for increasingly 
demanding payloads. 
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